fix(template): change UpdateTemplateArg.KeyUsage to *int to match Command API#58
Open
spbsoluble wants to merge 1 commit into
Open
fix(template): change UpdateTemplateArg.KeyUsage to *int to match Command API#58spbsoluble wants to merge 1 commit into
spbsoluble wants to merge 1 commit into
Conversation
…mand API
Command's TemplateUpdateRequest.KeyUsage and TemplateRetrievalResponse.KeyUsage
are both {"type":"integer","format":"int32"} per the v25.5 swagger — an int32
bitmask (e.g. 160 = digitalSignature|keyEncipherment). UpdateTemplateArg.KeyUsage
was typed *bool, which serializes as a JSON boolean and produces a live HTTP 400
from Command ("Unexpected character encountered while parsing value: t. Path
'KeyUsage'"), making the field unusable as-is.
GetTemplateResponse.KeyUsage was already int, so this also fixes the type
mismatch between the get and update models for the same field.
Also fixes the identical defect in v2/api/template_models.go for consistency;
v2 is tagged/released independently and is not part of this v3.6.0 change.
Adds TestUpdateTemplateArg_KeyUsage_SerializesAsInt to v3/api/template_test.go,
which fails to compile against the pre-fix *bool field and asserts the wire
payload is a JSON number.
spbsoluble
added a commit
to keyfactor-pub/terraform-provider-keyfactor
that referenced
this pull request
Jul 22, 2026
buildTemplateRoleBindingUpdateArg never carried KeyUsage from GetTemplate onto the UpdateTemplate request, so every role attach/detach silently reset the template's KeyUsage bitmask to 0 on Command even though this resource does not manage KeyUsage at all. Command's UpdateTemplate is a full replacement (PR #180 context), so any omitted field is cleared server-side. Pin keyfactor-go-client/v3 v3.6.0-rc.0 (Keyfactor/keyfactor-go-client#58), which changes UpdateTemplateArg.KeyUsage from *bool to *int to match Command's v25.5 wire format (int bitmask on both GET and PUT; a JSON boolean is rejected with HTTP 400). Use the non-collapsing pointer pattern already established in this function so a KeyUsage of 0 round- trips instead of being dropped by omitempty. TestUnitTemplateRoleBindingUpdatePreservesKeyUsage reproduces the wipe end-to-end against a mock Command server (GET returns KeyUsage 160, capture the PUT body) and fails on the unfixed code with the PUT body carrying no KeyUsage field at all.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
UpdateTemplateArg.KeyUsageis currently typed*boolin bothv3/api/template_models.goandv2/api/template_models.go. Command's live API disagrees:TemplateUpdateRequest.KeyUsageandTemplateRetrievalResponse.KeyUsageare both{"type":"integer","format":"int32"}per the v25.5 swagger — an int32 bitmask (e.g.160=digitalSignature|keyEncipherment).GetTemplateResponse.KeyUsagein this repo is already typedint, so the get/update models disagree with each other on top of disagreeing with the server.Unexpected character encountered while parsing value: t. Path 'KeyUsage'.This makes the field unusable as-is for any caller trying to round-trip
KeyUsagethrough a template update.Change
v3/api/template_models.go:UpdateTemplateArg.KeyUsage*bool→*int.v2/api/template_models.go: same fix, for consistency (v2 is tagged/released independently of v3 and is not part of the v3.6.0 target for this change).v3/api/template_test.go: addsTestUpdateTemplateArg_KeyUsage_SerializesAsInt, which fails to compile against the pre-fix*boolfield and asserts the JSON payload sent to Command is a number, not a boolean.This is a breaking type change, but the field was non-functional beforehand (any real use hit the 400 above), so there's no working caller to break. Targeted for v3.6.0.
Test plan
GOWORK=off go build ./...(v3 module)GOWORK=off go vet ./...(v3 module)GOWORK=off go test ./...(v3 module) — full suite passes, including the new regression testGOWORK=off go build ./...(v2 module) — builds clean (pre-existing, unrelatedgo vetfailure inv2/api/client_test.goconfirmed present before this change too, viagit stash)